Organizations rely on business intelligence (BI) to support decision-making. Business intelligence may support business decision-making by extracting information from business intelligence systems (such as data warehouses, for instance), analyzing the extracted information, and organizing the analyzed results into a desired structure to facilitate business decision-making. In some instances organizations may use different business warehouse systems, data analysis systems, and systems to organize or present the analyzed data in a desired structure. Each of these different systems may contain applications supplied by different vendors, and therefore have different interoperability interfaces.
Various protocols have been developed to ensure interoperability of these different business intelligence components. XML for Analytics (XMLA) is a simple object access protocol interface that is commonly used for data access for analytical purposes. However, XMLA requires multidimensional expressions (MDX) language statements to extract and manipulate data from online analytical processing databases typically found in business intelligence systems. Writing MDX statements requires programming skills which implies additional costs because of the necessary developer profiles required. Additionally, even if a developer of a consumer application is able to formulate a MDX statement to extract and manipulate the desired data, the resulting non-semantic output, an example of which is shown in FIG. 1a, is difficult to understand.
FIG. 1 shows an exemplary format of an input MDX statement 110 and an exemplary format of an output data set 120 when using XMLA. Creating MDX statements, such as statement 110, may not be intuitive for developers of consumer applications who may be unfamiliar with the formatting requirements and specifications of MDX. Developers of consumer applications may also have difficulty understanding the significance of XMLA data set output 120. For example, while the output 120 contains specific data values, such as 16890, 50, and 36175.2, there is no description or semantic meaning associated with the specific data values listed. Thus, it is not clear from the output 120 what the $36175.20 currency figure represents.
One reason that XMLA data set outputs, such as data set output 120, do not contain descriptions or semantic identifiers associated with the specific data values is that XMLA is designed to access and retrieve data from any BI system data provider. Because XMLA is designed as a universal protocol for accessing data from any data provider, the interface and the data set output 120 is generic and non-semantic.
However, in organizations with multiple computing systems, additional flexibility in using data output from business intelligence systems may be necessary. For example, instead of directly presenting the data set output, an organization may want to export the business intelligence system data output to another system, such as an enterprise resource planning system or a customer relationship management system. To ensure compatibility with these systems, the output data may have to be transformed to a format recognized by the other systems. The non-semantic query result output from these business intelligence systems makes it difficult for an organization to integrate the query result output into other systems and applications.
While it may be possible to manually create a program that provides the results of business intelligence system queries in a desired, semantically meaningful output format, the necessary manual implementation would be cumbersome and inefficient. Every time a new query is created or an existing query is substantially modified, the program would have to be altered to provide the queries results into the desired format. Not only is this process cumbersome and resource intensive, but it may also require specialized programming skills that may limit the number of individuals in an organization who can manually modify the program.
Other interfaces such as the Business Intelligence Consumer Services do not overcome these limitations. Although these interfaces support object models enabling selection of desired search criteria through a graphical user interface instead of through a programming syntax such as MDX, these interfaces also produce the same non-semantic output 120 shown in FIG. 1.
There is a need for an interface tool that automatically provides generic business intelligence system query results in an intuitive semantic structure easily consumable by other systems in an organization while providing non-programming, declarative data access.